码农必备技能：烂代码的处理之道（下）
接上一篇 烂代码的处理之道（上）
3. 封装成类
但是我们不会就此停步， 你再看看代码，发现这么多小函数的调用其实是很凌乱的， 尤其是一些参数在函数之间传来传去， 看起来很扎眼。
这是另外一种暗示： 你应该抽取出类了 ！
作为码农的你肯定知道什么是封装，是时候派上用场了， 把你的小函数及其相关的状态封装成类 ， 这将是一步巨大的跨越。
别忘了测试啊！
4. 屠龙刀：发现变化，并且封装变化
好，现在你看到曾经凌乱的领地， 秩序已经慢慢出现了， 各个类之间尽可能的隐藏自己的状态， 只通过方法来进行交互。
如果你的编程素养更高的话， 也许你能嗅到另外一种代码的坏味道： 类的职责划分不清--一个类搅进去了太多的职责， 读代码时脑子需要对很多职责进行不停转换，浪费脑细胞。
我一直认为 把不同的责任放到不同的类中去是非常重要的一件事情，更是程序员经常要修炼的基本素养， 但我观察发现， 很多程序员只会停留在把代码封装成类这一步， 而不会划分职责。
可能有人要问了，职责到底是啥？ Robert Martin （就是《敏捷软件开发，原则，模式，实践》的作者）有个精辟的描述： 职责就是引起变化的原因。
如果有多于一个的原因都可能引起类的变化，就违反了单一职责原则， 最好把职责划分开。
例如一个上传图片的类，调用httpclient来上传图片， 但是上传过程和上传成功都会更新界面， 此时就有两个变化的原因了， 一个是通过网络上传图片， 另一个是界面， 任何一个的变化都会引起这个类的变化， 好的设计需要拆分开。
这时候你的脑子里时刻要牢记一个原则： 发现变化并且封装变化， 拿着这柄屠龙刀对你的类进行毫不留情的重构吧。
5. 倚天剑：对接口编程而不要对实现编程
如果说屠龙刀让你大砍大杀，酣畅淋漓的话， 倚天剑的使用更加考验你的编程智慧， 因为它的使用更加精细微妙， 它考验的就是你的抽象能力。
你怎么样才能把一些相似的职责再抽象一下，形成更高层次的接口让别人调用， 进而隐藏自己的具体实现呢？
例如有两个类，一个类是把内容输出到打印机， 另外一个类把同样的内容输出到屏幕， 是不是可以抽象出一个print() 接口？
答案是: “不一定”， 得看你具体的业务，具体的代码。
我相信做接口抽象没有通用的方案，但是前辈们的总结已经给我们指明了方向和目标， 那就是“设计模式”。
只要你对职责的抽象向着设计模式的方向挺进， 基本上是不会跑偏的。
这里不会再展开讲设计模式，我记得我的IBM经理说过：”10年前我们面试的时候，还会问懂不懂设计模式， 现在不会问了， 因为懂得设计模式已经是必备的技能“ 请各位程序员再仔细的品味一下《设计模式》这本书，我承认它举的例子比较古老，读起来也非常费劲， 但它里边散发出的思想是永恒的。
从具体到抽象是你能力的更大跨越， 很多程序员迈不过这一步，或者说他自以为迈过去了，实际上却没有， 因为不恰当的抽象、或者过度的抽象反而是一种危害。 我现在也不敢说掌握了这个技能， 只能说继续学习，继续进步。
6. 无招胜有招
好了，上面的都是废话，你现在可以统统忘了，:-) 但是要记住下面讲的终极武器：无招胜有招。
仔细想一下为什么我们编程序这么费劲呢？
说白了就是复杂的需求和“愚蠢”的编程语言之间有极大的隔阂，所以需要我们程序员的大脑来填补。
别看现在有各种各样的编程语言出现， 每个语言都吹得天花乱坠，但其实还都是”很低级的“ ，到目前为止，我们依然没有办法以自然语言的方式来编程序， 程序员为了把现实的业务映射到计算机实现， 需要累死无数脑细胞。
由于人脑同一时刻不能处理太多东西， 当我们面对太多的变量因素时，只能处理其中有限的几个， 这就逼着我们使用”发现变化，并且封装变化“， ”对接口编程而不是对实现编程“ 这样的武器， 把细节隐藏，把变化隔离。
其实这两样武器的终极目的就是为了达到程序的”正交性“。
“正交”在数学上讲的是线性无关， 是说一个维度的变化不影响另外一个维度， 你想象一下我们常用的二维坐标系(x, y) , x轴的变化不会影响到y轴的值， 反之亦然， 这就是正交性的体现。
但正交性的威力远远不止于此， 对于(x,y) 能表达二维空间中的所有的点， 如果我们再增加一个新的和x,y正交的维度z 轴， 那一下子就能表示三维空间中的所有的点了！
软件编程也是如此，无论你使用何种方法， 就是让程序形成互不影响、可以独立变化的多个维度， 这样的程序不仅优雅漂亮，更是容易理解，容易维护。
我想“正交性”应该是我们编程时追求的终极目标， 你可以忘掉其他招式，无往而不胜。
长按二维码， 关注"coderising"
加入QQ群：135769418 工作15年的的IBM架构师带着你做项目实战， 可是真的项目需求哦，涉及大量Android,iOS, Web开发的技术， 同学们做完后参加工作，技术上就不用愁了。